Co-authored-by: Bastian Kauschke <[email protected]>

…unction

Signed-off-by: Nell Shamrell <[email protected]>

This new version includes a fix for building on aarch64 windows.

Added io forwarding methods to the stdio structs

Added methods to forward the `io::Read` and `io::Write` methods of the myriad wrapper structs in `stdio.rs` to their underlying readers / writers. This is especially important for the structs on the outside of a locking boundary, to ensure that the lock isn't being dropped and re-acquired in a loop.

…ewjasper

MIR sanity check: validate types on assignment

This expands the MIR validation added by @jonas-schievink in rust-lang#72093 to also check that on an assignment, the types of both sides match.

Cc @eddyb @oli-obk

…Amanieu

Add documentation to point to `File::open` or `OpenOptions::open` instead of `is_file` to check read/write possibility

Fixes rust-lang#64170.

This adds documentation to point user towards `!is_dir` instead of `is_file` when all they want to is read from a source.

I ran `rg "fn is_file\("` to find all `is_file` methods, I hope I did not miss one.

Prepare for LLVM 11

These are just the code changes needed to build with the current LLVM master (version 11).

r? @nikic

Adds a clearer message for when the async keyword is missing from a f…

…unction

This is a somewhat simple fix for rust-lang#66731.

Under the current version of Rust, if a user has a rust file that looks like this:

```rust
fn boo (){}

async fn foo() {
    boo().await;
}

fn main() {

}
```

And they attempt to run it, they will receive an error message that looks like this:

```bash
error: incorrect use of `await`                                                                                                        --> test.rs:4:14                                                                                                                       |                                                                                                                                   4 |     boo.await();                                                                                                                    |              ^^ help: `await` is not a method call, remove the parentheses                                                                                                                                                                                              error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied                                                        --> test.rs:4:5                                                                                                                        |                                                                                                                                  4  |     boo.await();                                                                                                                    |     ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}`                                                                                                                                                                                      error: aborting due to 2 previous errors                                                                                                                                                                                                                                    For more information about this error, try `rustc --explain E0277`.
```

This is not very clear.

With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:

```bash
error[E0277]: `()` is not a future.
 --> test.rs:4:5
  |
4 |     boo().await;
  |     ^^^^^^^^^^^ `()` is not a future
  |
  = help: the trait `std::future::Future` is not implemented for `()`
  = note: required by `std::future::Future::poll`
```

In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](rust-lang#66731 (comment)). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.

Signed-off-by: Nell Shamrell <[email protected]>

fix typo in self-profile.md

Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.